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I I Abstract 

A recent development in formal security protocol analysis is the Protocol Composition Logic 
, (PCL). We identify a number of problems with this logic as well as with extensions of the 

^ ■ logic, as defined in [DDMP05,HSD+05,He05,Dat05,Der06,DDMR07]. The identified problems 

, imply strong restrictions on the scope of PCL, and imply that some currently claimed PCL 

proofs cannot be proven within the logic, or make use of unsound axioms. Where possible, 
we propose solutions for these problems. 

> , 

^ ■ 1 Introduction 

O 



Formally establishing properties of security protocols has been investigated extensively during the 
last twenty years, but a definite model and a corresponding method for security protocol analysis 
has remained elusive thus far. 
I The most successful approaches to security protocol analysis have been focused on tools 

' for finding attacks, which are often based on bounded model checking or constraint solving, 

e.g. [Low97a, ABB"'"05]. When such tools find an attack, one can easily verify manually whether 
, . ■ or not the attack actually exists on the protocol. Some tools even allow for unbounded verification 

r> I of protocols, e.g. [BlaOl, Cre06]. If no attack is found with such tools, correctness of the protocol 

' follows. However, this provides little insight into why a protocol is correct. 

An alternative approach is to develop a logic for reasoning about security protocols. When 
a protocol is proven correct in such a logic, the derivation steps can provide insight into the 
mechanisms that make the protocol work. Despite the obvious promise of such an approach, 
several attempts have failed, most notably the BAN logic from [BAN90]. One of the stumbling 
points seems to be to provide a logic that is sound with respect to the complicated semantics of 
security protocol execution in the presence of an active intruder, and is able to provide concise 
formal proofs. 

A recent attempt to develop such a logic is the Protocol Composition Logic (PCL) from 
e.g. [DDMR07]. This logic has evolved from a protocol model to express protocol composition 
and refinement, into a model with an associated logic that can be used to formally prove security 
properties of protocols [DDMP05,Dat05,Der06]. Variants of PCL have been applied to many case 
studies and offer several interesting features. For example, one can reason about security protocols 
without explicitly reasoning about the (complex) intruder by means of a special kind of invariant 
reasoning captured by the honesty rule. This kind of reasoning also allows the protocol logic to deal 
with protocol composition and refinement, where proofs can be reused. PCL has been extended 
with several features in further work, such as an extension for hash functions in [HSD+05] that 
was used for a modular correctness proof of IEEE 802.111 and TLS. 
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In this paper, we identify a number of problems with PCL as defined in [DDMP05, Dat05, 
Der06,DDMR07, HSD+05,He05]. They have imphcations for the scope of PCL, a number of 
claimed formal proofs, and several extensions to the base model. In particular, we show that 
in contrast with the claims in e.g. the introduction of [DDMR07], PCL as defined in [DDMP05, 
Dat05, Der06, DDMR07] cannot be used to prove common authentication properties of protocols 
that do not include signatures. We show that a number of claimed proofs in PCL cannot be 
correct because (a) there is no way to establish preceding actions in a thread, and (b) there is 
no way to express type restrictions in PCL. With respect to existing PCL extensions, we identify 
two problems: the Diffie-Hellman extension from [DDMP05, Dat05, Der06, DDMR07] does not 
correctly capture the algebraic behaviour of Difhe-Hellman-like protocols, and the extension for 
hash functions from [HSD+05, IIe05] is not sound. Some of these problems can be resolved by 
minor modifications to PCL, but other problems require further investigation. Our observations 
suggest that it is at least required to make changes to existing axioms, to introduce new axioms, 
and to add a mechanism for a type system. 

The purpose of this paper is to identify some of the challenges that need to be addressed in 
order to make a logic like PCL work. We hope it will contribute to the improvement of PCL, 
and will lead to a better understanding of some of the pitfalls of designing a compact and usable 
formal logic for security protocols. 

The scope of this paper. The presentation of this paper is inherently difficult, not least be- 
cause there are a number of different papers on PCL, which vary in notation and technical details. 
Many ideas were already present in precursors of PCL, e.g. [DMP01,DMP03], but these variants 
use different concepts than later versions of PCL. These early variants in [DMPOl, DMP03] have 
no notion of thread (a.k.a. process, run, or role instance), and events are bound to agents. More 
recent versions of PCL bind events to threads of agents, and therefore distinguish between several 
threads of the same agent. PCL versions of the latter type can be found in [DDMP03b,DDMP03a, 
DDMP04b,DDMP04a]. Subsequently, [DDMP03b, DDMPOSa, DDMP04b, DDMP04a] have been 
claimed to be either subsumed, or revised and extended, by more recent works [DDMP05, Dat05, 
Der06,DDMR07]. Hence we choose here to focus on [DDMP05,Dat05,Der06,DDMR07], which 
contain similar descriptions of PCL. Throughout this paper we write basic PCL to refer to 
[DDMP05,Dat05,Dcr06,DDMR07]. The pubhcations on basic PCL describe the fundamental 
part of PCL that focusses on authentication. In general, the comments in this paper apply to 
basic PCL. The comments in Section IT2l applv only to the extensions found in [HSD+05,IIe05]. 
Our comments here do not cover the recent extensions to basic PCL for the analysis of secrecy, as 
found in [RDD+06], nor the computational variants of PCL, as found in e.g. [DDMW06]. 

SyntELX and page references. In order to pinpoint our observations to specific formulas, we 
select a specific version of PCL to refer to. We have chosen the most recent description of PCL from 
2007 as found in [DDMR07]. In particular, we will use [DDMR07] as a reference for the syntax of 
PCL formulas, and to provide specific page references. Hence we use [DDMR07] as the reference 
paper to present the problems with basic PCL from the papers [DDMP05,Dat05,Der06,DDMR07]. 

For the technical details, in particular the formulas, we assume the reader is at least some- 
what familiar with one of the papers from [DDMPG5,Dat05,Der06,DDMR07] or [He05,HSD+05]. 
However, the main points should be clear to readers familiar with formal security protocol analysis. 

The remainder of the paper is structured in the following way. We start off by recalling some 
PCL notation and concepts in Section [2l Then, in Section [3] we discuss problems with the basic 
definition of PCL. In Section |4] we identify two problems with existing PCL extensions. We 
conclude in Section [51 

Acknowledgements. The author would like to thank David Basin, Anupam Datta, Felix 
Klaedtke, Sjouke Mauw, Simon Meier, John C. Mitchell, Arnab Roy and the anonymous referees 
for useful discussions and feedback on earlier versions of this paper. 
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2 Preliminaries 



The purpose of this section is to recaU some PCL notions that are required to interpret the 
forthcoming sections. We use the syntax from [DDMR07]. This partial summary of PCL is 
incomplete, and we encourage the reader to use the original papers for reference. 

The structure of PCL is as follows: first notation is introduced to define terms, which in turn 
are used to define protocols. For such protocols, an execution model is defined, assigning to each 
protocol a set of possible execution histories, called runs. Then, a protocol logic is defined in 
order to reason about (sets of) runs of a protocol. This logic is proven sound with respect to the 
execution model. This means that if one proves a property in terms of the protocol logic, such 
as Receive(. . . ,m), then a similar property should hold for the corresponding set of runs in the 
execution model, such as "receive . .. ,m has occurred in the protocol run". We touch upon 
these elements below. 

Terms. A term system is introduced that contains constants (nonces, names, keys, etc.), 
variables, and compound terms such as tuples, encryptions, and signatures. 

Protocols. In PCL, a protocol Q is defined as a set of roles. Each role p € Q is defined as 
a list of actions. Examples of possible actions can be found in the actions column of Table [TJ 
and correspond respectively to sending terms, receiving terms, generating fresh terms, encryption, 
decryption, and signature verification. Each role is partitioned into a set of basic sequences. A basic 
sequence BS^ of a role p is a contiguous subsequence of p that starts with either the first action of p 
or a receive action, and of which the other actions are not receive actions. The basic sequences 
intuitively represent the idea that agents only block at receive actions, and execute all other 
actions immediately, allowing one to regard basic sequences as atomic actions in some respects. 
The notion of basic sequences therefore roughly corresponds to the notion of step-compression in 
other models, e.g. [BMV03]. The basic sequences of a protocol are defined as the union of the 
basic sequences of each of its roles, and hence each action of a role of a protocol occurs in exactly 
one of its basic sequences. 

Observe that although some versions of PCL have two distinct actions receive (for reading a 
term from the network without parsing) and match (for parsing a term and blocking if it is not as 
expected), these two actions are in many proofs collapsed together into a single receive action 
that receives and matches terms at the same time. 

Execution modeL An execution model is defined for protocols (in terms of cords). Actions 
are executed by agents, with names like X,Y. A subset of these agents, defined as HONEST{C) 
(where C is the initial configuration of the system) , are called the honest agents, and execute their 
protocol roles as expected. The agents may execute each protocol role any number of times; each 
such instance of a role is called a thread (in other formalisms, this notion is known as a strand, or a 
process, or a run). Threads are usually denoted by symbols such as X, Y, Z: a sequence of actions 
P executed within a thread X is written as [P]x- The notation X is used to denote the 

agent executing the thread X. Informally, if the agent X is honest, [P]x is a sequence of actions 
from a protocol role. The agents that are not part of HONESTiC) can execute so-called intruder 
roles, in line with the common Dolev-Yao intruder model. In the context of this execution model, 
the protocol description Q gives rise to a set of runs denoted by Runs((5). A run is typically 
denoted by R, and corresponds to a sequence of actions as executed by threads. A run represents 
a possible execution history of the system. 

Protocol logic. For each of the actions that can occur in a run, a corresponding action 
predicate is defined. Some examples are given in the right column of Table [TJ The protocol logic 

^The hat notation "is used in at least two different interpretations in both [DDMP05] and [DDMR07]. In some 
cases X is used to denote a particular thread, and X is then interpreted as the agent that executes that thread, 
as e.g. can be seen in the usage of Y in the SEC axiom [DDMR07, page 327], replicated here on page|6] Thus, in 
one interpretation " can be regarded as a function from a thread to an agent. However, in other cases X is used to 
denote a particular agent, and X is then interpreted as "any thread executed by the agent X" , as in the honesty 
rule HON [DDMR07, page 329], and the VER axiom [DDMR07, pp. 329-330], repUcated here on page [5] In 
this second interpretation, X is a variable that ranges over all threads executed by the agent X, and X effectively 
expresses a domain restriction on X . 
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Action 


Associated term 
structure 


Predicate 
(in thread X) 


send X, Y , m 
receive X, Y , m 
new X 
enc m, K 
dec enrf, if 
verify sigt, m, K 


end = ENCk^ m |} 
enci = ENCKlml 
sigt — SIGk^ rn |} 


Send(A', to) 
Receive(Ar, to) 
Gen(A', x) 
Encrypt(Ar, end) 
Decrypt(Ar, end) 
Verify(X, sigt) 
Has(X, m) 
Honest(X) 

Contains(6i(7i, smallt) 



Table 1: Some examples of PCL actions, action predicates, terms, and their relations. Here X,Y 
denote agents, to, x, enct, sigt, bigt, smallt denote terms, and X denotes a thread. 

is extended with logical connectives, a predicate to reason about the ordering of actions in a run 
(<), as well as predicates to reason about the knowledge of threads. 

One of the predicates of the logic is the Honest predicate, which is closely related to the set 
HONEST{C). For a run R, Honest(X) is used to denote that X e HONEST{C) and "all threads 
of X are in a 'pausing' state in i?" [DDMR07, page 325]. This is a technicalitjo that is needed to 
make the honesty rule (which is not described here) work. 

One predicate of interest for this paper is the Contains predicate, which is used to reason about 
the relation between two terms. In particular, Contains(ti, t2) is defined by means of the subterm 
relation C in [DDMR07, page 323] , stating that ti contains t2 as a subterm. The subterm relation 
C is never formally defined. Here we assume that the subterm relation is defined syntacticalljU. In 
particular, we assume that a signature such as SIG^^ m |} contains to, i.e. Contains(;S/G'^{] to |}, to) 
holds. Note that this assumption only plays a role in the construction of a particular counterex- 
ample in Section [3.31 and does not influence any of our general observations. 

Using the protocol logic, one aims to establish properties of all runs of a protocol. A run R of 
a protocol Q that satisfies a property (j) is denoted as Q,R\= (j). If all runs of a protocol Q satisfy 
(j), we write Q \= (j). If a formula (f) is provable using the logic by using any PCL axioms except the 
honesty rule, we write h (/), which expresses that (j) holds for all protocols. For formulas provable 
using the axioms and the honesty rule for a protocol Q, we write hg (p, which expresses that (j) 
holds for the protocol Q. 

In the remainder of this paper we use the following convention: All formulas that are numbered 
are ours. All unnumbered formulas, including the named axioms, are copied from PCL papers, in 
which case the source paper and page number is given. 

3 Problems with basic PCL 

In this section, we address two problems with basic PCL as defined in [DDMP05, Dat05, Der06, 
DDMR07]. First, we identify in Section [37l1 a strong restriction on the scope of basic PCL. Then, 
we identify two missing proof mechanisms that seem to be necessary to prove simple protocols 
correct in Sections 13.21 and 13.31 

^The Honest predicate serves within the honesty rule as an encoding of the atomic nature of basic sequences. 

^Observe that if we would alternatively assume that the subterm relation involves only tuple projection, as seems 
to be suggested by the CON axiom [DDMP05, page 444], i.e. t C t' = {t = t') W {3t" .t' = {t,t") V t' = it" ,t)), 
then e.g. the P2 and VER axioms in [DDMP05, DDMR07] are unsound, because respectively the fresh value and 
the signature might be sent as part of an encrypted term, and decrypted by an agent that knows the key. 
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3.1 Authentication properties only provable for signature protocols 

In basic PCL [DDMP05, Dat05, Der06, DDMR07], the possibility of proving authentication prop- 
erties is hmited to protocols that use signatures. 

Proving an authentication property such as aliveness or agreement requires a proof of existence 
of actions of another agent. In basic PCL, there is only one axiom that allows for a conclusion 
of that type. The precondition of this axiom can only be met by protocols that use signatures. 
As a consequence, if a protocol does not use signatures, the existence of a communication partner 
cannot be proven within the logic. 

This is surprising, as PCL was "initially designed as a logic of authentication" [DDMR07, page 
313], and it is stated in the abstract of the paper that "PCL [. . . ] has been applied to a number 
of industry standards including SSL/TLS. IEEE 802. Hi [...]" [DDMR07, page 311, abstract]. 
These protocols consist of many subprotocols that do not rely only on signatures, but also rely on 
symmetric key cryptography and symmetric MACs. 

The problem occius for all authentication properties that imply the existence of a communica- 
tion partner. This includes aliveness or any form of agreement from [Low97b], matching conver- 
sations from [BR94] , or synchronisation from [CMdV06] . The matching conversations property is 
the authentication property used within basic PCL [DDMR07, page 331]. All these properties are 
of the form: 

ct>{X) D 3F.V(y) (1) 

where typically, 4>{X) denotes that thread X executes a role that authenticates another role. Such 
a property states that if a thread X executes actions of a certain role (e.g. all actions of an initiator 
role), then there exists a thread Y that has executed some actions of another role (e.g. the first two 
actions of a responder role), and possibly some further condition holds. This is captured in il>{Y). 
Note that both the weak and strong authentication properties in the example of [DDMR07, page 
331] belong to this class of authentication properties. 

In order to prove such a property, it is required to prove the existence of a thread. Examination 
of all axioms of the logic reveals that only one axiom allows for the conclusion of the existence of 
a thread, which is the VER axiom [DDMR07, page 327]: 

VER Honest(i') A Verify(r, SIG^f^ x^)AXj^Yd 

3X.Send(X, m) A Contains(m, S'/G^j] x [[) 

Because this axiom has the signature verification predicate Verify in the precondition, it can only 
be used for signature protocols. Hence there is no way to prove the existence of another thread 
for protocols without signatures. 

Other comments regarding non-signature protocols. Whilst introducing new axioms for 
establishing thread existence for non-signature protocols is non-trivial, there is a related problem 
with the inconsistent use of symmetric/asymmetric cryptography. In basic PCL, there is only one 
type of encryption operator, and only a single key set, in the sense that the rules for encryption 
and decryption do not distinguish between different types of keys. This suggests that either only 
symmetric, or only asymmetric encryption is supported. 

The definitions of the reaction rules [DDMR07, page 318], the action formulas [DDMR07, page 
324] and the Has predicate [DDMR07, pp. 324-325] all indicate that one encrypts and decrypts a 
message using the same key, e.g.: 

Has,+i{A,ENCK^m\i) if Has^{A,m) and Has,{A, K) 
HaSj+i(A,m) if HaSi{A, ENCK^m \}) and Has,{ A, K) 

The same assumption, that one encrypts and decrypts with the same key, can be found in axiom 
AR3 [DDMR07, page 327]. Without explaining the full details of the notation of this axiom, we 
want to point out that the key K is used as the key to decrypt a message encrypted with K: 

AR3 aix) [y := dec x, K]x aiENCx^ y ^) 
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However, the idea that symmetric encryption is intended seems to be contradicted by the SEC 
axiom [DDMR07, page 327], which states that there is only one agent that can decrypt a message 
encrypted with a key, along the lines of asymmetric encryption: 

SEC Honest(l) A Decrypt(y, ENCj^^ x^)d {Y ^ X) 

Combined with the definition of the Has predicate, one is lead to conclude that the only one who 
can create the encrypted message that occurs in the SEC axiom, is the agent that can decrypt it. 

3.1.1 Implications 

In order to prove any authentication property of the form of ([1]) for a protocol that does not use sig- 
natures, one needs to introduce consistent machinery for symmetric and asymmetric cryptography 
and several new axioms. 

In basic PCL, protocols like Needham-Schroeder-Low^^ and many key establishment protocols 
cannot be modeled, and even if they could be, no authentication proofs could be given for them. 
Similarly, it is impossible to use basic PCL as defined in [DDMP05, Dat05, Dcr06, DDMR07] to 
prove the authentication properties of the protocols "SSL/TLS, IEEE 802.111" [DDMR07, page 
311, abstract]. In order to prove authentication of these protocols, one is required to introduce 
additional axioms. 

3.1.2 Resolving the problem 

The problem can be split into three subparts. First, symmetric and asymmetric cryptography must 
be dealt with consistently. Second, basic PCL must be extended with axioms that enable proving 
authentication properties (existence of a thread) for symmetric cryptography. Third, resolving the 
problem for public-key encryption protocols (which includes many key agreement protocols, and 
the well-known Needham-Schroeder-Lowe protocol) requires the introduction of additional theory. 
We first address the two easier problems before turning to public-key encryption. 

Dealing consistently v^rith symmetric and asymmetric cryptography. The first require- 
ment for resolving this problem is to split symmetric and asymmetric encryption either by hav- 
ing two types of encrypt/decrypt actions as in e.g. [ABB+05], or by splitting the key set as in 
e.g. [Cre06]. Either choice impacts the action sets, the action formulas, the Has predicate, and 
requires the addition of further ARx axioms and an alternative for the SEC axiom. Most of 
the additions are trivial, but introduce additional complexity into the logic and possibly also the 
execution model. 

Proving authentication for protocols using symmetric encryption or keyed hashes. 

The axiom for signature protocols deals with the simplest possible case of authentication by 
cryptography: the signature of an honest agent can be used immediately to conclude that there 
exists a thread executed by this agent. If that agent differs from any agent executing the currently 
known threads, this implies the existence of another thread. This conclusion is based on the fact 
that only one agent has the private key needed to perform the signature. 

For symmetric encryption and keyed hashes there is usually a notion of symmetry: in most 
cases, two agents share a symmetric key. Thus, if a symmetric key K shared by two honest agents 
X and Y, occurs in a message of a thread X, there are two candidates for the agent who created 
the message. If we can exclude that the message was generated in thread X executed by X, we 
can derive the existence of another thread Y that must have created it. 

The authors of PCL have explored a variant of this route for e.g. the extensions needed for the 
keyed-hash based protocols in [HSD+05]. We discuss the merits of those extensions in detail in 
Section [Ol 

^Observe that in a precursor of PCL in [DMP03] there is a proof of Needham-Schroeder-Lowe, but this logic 
has only asymmetric cryptography, and has no notion of threads or processes. 
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Proving authentication for public-key encryption protocols. If we assume that basic 
PCL is extended to consistently deal with public-key encryption, the authentication properties 
still cannot be proven, as we lack an axiom for establishing thread existence as pointed out 
previously. Contrary to signatures or symmetric-key cryptography, there is no easy solution with 
an axiom based on honest agents only, because the public keys are also known to the intruder. If 
a message encrypted with the public key of an honest agent X occurs, no conclusion can be drawn 
about the sender or creator of the message. Thus we must also consider the possibility that the 
message was sent by the adversary. 

A first step towards a solution would be to introduce an axiom in the protocol logic, along 
the lines of Lemma 2.3 [DDMR07, page 321] of the execution model. In fact, such an axiom was 
present in a precursor of basic PCL. In [DMP03, page 701] one can find axiom ARl which, when 
recast in the basic PCL model, would read 

ARl [receive t]x3Z.Send(Z, t) (This axiom is not in basic PCL) (2) 

A second axiom that might be adapted for proving these properties is the SRC axiom in [DMP03, 
page 703]. 

Unfortunately, for either of these axioms, authentication proofs would require either further 
machinery to prove that Z is executed by an honest agent, or explicit reasoning about the intruder, 
as the sender thread Z need not be executed by an honest agent. This type of reasoning is not 
supported by basic PCL, and would require a significant amount of additional machinery. 

3.2 No means to establish preceding actions in a thread 

By the definition of the PCL execution model, threads of honest agents start at the beginning of 
a role description, and always execute the actions in the order given by the role. Thus, if one can 
establish that a thread of an honest agent has executed the nth action of a role, it should also be 
possible to conclude a similar result about preceding actions within the logic: in particular, one 
should be able to conclude that the preceding n — 1 actions have also occurred in the same thread. 
However, there is no mechanism in the logic of basic PCL [DDMP05, Dat05, Der06, DDMR07] to 
draw such a conclusion. 

Note that one can use the honesty rule to prove from, e.g., a send action that a receive action 
must have occiirred previously, but only if both actions occur within the same basic sequence. 
However, if one wants to prove that given a basic sequence, an action has occurred from another 
basic sequence, there are no rules to enable this type of reasoning. 

3.2.1 Implications 

The consequence of not having a means of establishing preceding actions is that some claimed 
proofs do not seem to be correct. For example, observe the initiator role of the Qcr protocol 
[DDMR07, page 315]. In order to prove invariants for the protocol using the honesty rule, one has 
to prove that the invariants hold for all basic sequences of the protocol. The initiator role consists 
of two basic sequences BSi and BS2 [DDMR07, page 335]: 

BSi = [newm; send X ,Y,m; ]x 

BS2 = [ receive y, X, y, s; verify s,{y,m,X),Y; r := sign {y,m.,Y), X; send X,Y,r; ]x 

In this protocol, the basic sequence BSi defines m as a generated value, which determines the 
semantics of m in BS2. Observe that there is no way to tell if m was received or generated from 
just investigating BS2. 

In order to show how this makes certain proofs impossible in basic PCL, consider a protocol 
Q', that contains a role p consisting of the basic sequences BS'^ followed by BS2, where BS'^ is 
defined as: 

BS'i = [receive ENCk^ m I, send X, Y, m; ]x (3) 
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Thus the protocol Q' shares the basic sequence BS2 with Qcrj but in Q', m is a received valued 
as opposed to a generated value. 

Now, in order to prove invariant 71 [DDMR07, page 334] for basic sequence BS2, we must 
prove that m is either generated, or received earlier as the main message, by the same thread that 
sends out the signature: 

71 = (Send(y, t) A Contains(f, SIGyl y, m, X ^)) D 

(Gen(y, m) V (Receive(F, (X, F, m)) < Send(y, (F, X, y, SIG^^ y, m, X |})))) 

In order to prove this invariant with respect to basic sequence BS2, one needs to prove that m 
is generated in the thread Y . However, there is no mechanism to reason about any preceding 
actions, and thus it has to be dealt with in the same way for both protocols Qcr and Q' . One 
must therefore also consider the case m was first received, and not generated, in a previous basic 
sequence as part of a bigger term, as happens in Q' . In fact, the invariant is false for protocol Q' . 

Thus, in order to prove the invariant for QcRj we must be able to distinguish between the 
different semantics of BS2 within the context of QcR and Q' . Such reasoning is not supported by 
basic PCL. 

Without the ability to reason about preceding actions, the protocol descriptions are effectively 
cut up into independent basic sequences, which can then only be dealt with as separate protocols. 
This is evident from the formulation of the honesty rule [DDMR07, page 329], in which the 
reference to the protocol Q is only used for the definition of the basic sequences. Thus one is 
required to create much stronger proofs than would be strictly necessary. Put differently, in basic 
PCL one has to reason with an over approximation of protocol execution, in which basic sequences 
occur in no fixed order in a thread. 

This phenomenon can also be observed in the following example. Let P be a protocol, and let 
Pi be the protocol defined as P extended with a role consisting of the basic sequences BS; BS'; BS". 
Similarly, let P2 be defined as P extended with a role BS"; BS'; BS, i.e., a role with the same basic 
sequences as the role in Pi, but composed in a different order. Then, any invariant 7 that can be 
proven for protocol Pi using the honesty rule, must also hold for P2. In fact, the proof is identical. 
Conversely, any invariant that holds for Pi but not for P2, cannot be proven using the honesty 
rule. This puts a strong restriction on the type of invariants provable in basic PCL, because the 
structure (and hence the properties) of both protocols can be very different. 

Ultimately, this problem seems to be a side effect of the weak link between the protocol 
description Q and the actions of honest agents in a run R e Runs((5) in the protocol logic. In 
basic PCL, the only way to make the link between a protocol description and the actions of honest 
agents, is by means of defining an invariant and then proving it with the honesty rule. This 
can be seen from inspecting the protocol logic rules: the only occurrences of a protocol name 
(e.g. Q) are in the honesty rule and the composition rules. As the honesty rule only reasons about 
isolated basic sequences of the protocol, the relations among the basic sequences of the protocol 
are inevitably lost. 

3.2.2 Resolving the problem 

Based on the semantics of PCL, it should be possible to extend the logic with a "precedence" 
inference rule, that would allow one to infer that given the nth action of a role p occurs in a 
thread X, also the (n — l)th action of the same role must have previously occurred in the same 
thread. Such an inference rule would allow for establishing preceding actions that must have 
occurred from the existence of other actions. This is particularly useful for proving invariants for 
basic sequences. 

In general one could extend basic PCL with additional mechanisms to enable reasoning about 
the relation between protocol descriptions and the actions of honest agents in a run. However, the 
current weak link between the two has one major advantage: it eases compositional proofs. For 
example, because no constraints are put on any other (i.e. non-protocol) actions of honest agents. 
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the sequential composition of protocols allows for re- use of proofs of invariants for basic sequences. 
Thus, one must be careful when introducing such links and introduce only links between the 
protocol and the actions of honest agent, such that the links are invariant under e.g. sequential 
composition. A "precedence" inference rule of the type sketched above should meet this condition. 

3.3 No formal type system 

It is mentioned that in PCL, "We assume enough typing to distinguish the keys K from the 
principals A, the nonces n and so on." [DDMR07, page 316]. However, there are no constructs in 
PCL that allow for formal reasoning about the type of variables. 

As a consequence, some claimed proofs of invariants are not correct within the logic, as they 
are only true under type assumptions, that cannot be expressed in PCL. 

3.3.1 Implications 

Many protocols have properties in a typed model, that do not hold for an untyped model. In 
particular, some protocols are correct in a typed model, but are vulnerable to so-called type flaw 
attacks in an untyped model. Such attacks exploit for example that an agent could mistake an 
encrypted session key for an encrypted nonce, and sends the key unencrypted in a next step, 
revealing it to the intruder. It is therefore often easier to prove properties for the typed model, 
but this requires that the logic supports drawing conclusions based on types. Currently, this is 
not possible in PCL. 

As an example, we show that invariant 71 from [DDMR07, page 334] (reproduced in this paper 
on page [8]) is false when variables are untyped. The invariant 71 states that if a thread (of an 
honest agent) sends a message that contains a signature term S, with a subterm to, then either 

1. TO was generated in the thread Y ^ or 

2. the thread Y executes a receive of m, and later a send of the message tuple (y, S). 
Now consider the basic sequence BS3 from [DDMR07, page 335]: 

BS3 = [ receive X, Y, x; new n; r := sign (n, x, X), Y] send Y , X, n, r; ]y 

This basic sequence corresponds to the responder receiving an unknown value, supposedly a nonce, 
and sending back a signed version that includes a freshly generated nonce. 

In order to show the invariant is false, consider a thread Y' that is executed by agent Y . If we 
assume that x — SIGy^ 2/: A" [[, where m is generated by thread Y' , the invariant is violated: 
we have that x = SIGy^ 2/: "^1 AT H 3 Contains(a;, to) and by substitution in BS3 and the Contains 
predicate, we find that Contains(r, to). As a result, the message sent at the end of BS3 of a thread 
Y {Y' ^ Y) will contain m. However, to is neither generated by this thread nor is it the exact 
term that was received. Thus the invariant 71 does not hold for basic sequence BS3. Hence the 
example authentication proof of the CR protocol in [DDMR07] is incorrect. 

3.3.2 Resolving the problem 

The model can be extended with typing information for the variables, and an axiom could be 
introduced that captures the fact that variables are only instantiated by their typing information. 
This would not introduce much new machinery, but requires additional reasoning steps in most of 
the proofs. 

4 Problems with PCL extensions 

In this Section we discuss two additional mechanisms for PCL, in particular the extension for 
Diffie-Hellman exponentials as found in [DDMP05,Dat05,Der06,DDMR07] and the extension for 
hash functions from [He05,HSD+05]. 
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4.1 DifRe-Hellman exponentials 



In basic PCL [DDMP05,Dat05,Der06,DDMR07], axioms are provided for reasoning about DifBe- 
Hellman (DH) exponentials. To that end, the logic is extended with four additional axioms and 
some changes are made to the language and execution model. 

4.1.1 Capturing Diffie-Hellman behaviour 

Below we recall the three elements of the DH extension (execution model, logic, proof system) 
and discuss their implications. 

DH extension of the language and execution model. The programming language and 
execution model are extended [DDMR07, page 354] with constructs g{a) and h{a,b), representing 
respectively g" mod p and {g"' mod p)^ mod p. In the PCL papers, the mod p and brackets are 
usually omitted, resulting in the abbreviations g° and g"**. 

This extension does not reflect the actual algebraic properties of the exponential. For DifHe- 
Hellman, the crucial property is that g"'^ = g^". This equation must be included in the execution 
model: if it is not, the following sequence of actions (denoted by their action predicates), which is 
perfectly valid DH-type behaviour, docs not correspond to a valid execution in PCL: 

Send(X, h{a, b)) < Receive(r, h{b, a)) (4) 

Just extending the Has predicate in the logic is not sufficient, as the equivalence still has no 
counterpart in the execution model of PCL. 

DH extension of the protocol logic. In basic PCL, the predicate Fresh (X,x) holds for any 
X generated by thread X (captured by Gen{X,x)), as long as x is not sent as part of another 
term. The protocol logic is extended with an additional rule for the Fresh predicate, stating that 
Fresh (X, (7(x)) is true if and only if Fresh(X, a;) is true, and Has is extended in [DDMR07, page 

354] by 

Has(X, a) A Has{X, g{b)) D Has{X, h{a, b)) A Has{X, h{b, a)) 

This rule is intended to capture the DifEe-Hellman equivalence relation. It is not sufficient, even 
with the addition of further axioms, as we show below. 

DH extension of the proof system. The proof system is extended in [DDMR07, page 354, 
Table A.l] by a definition and four new axioms. We reproduce them here: 

Define Computes (DH) 

Computes(X,5"'') = ((Has(X,a) A Has{X,g'')) V (Has(X,6) A Has(X,c/«))) 

This definition captures the intuition that a thread can compute the value of g'^^ if and only if 
it has the required components. Note that for a thread that just has but not a or b, this 
predicate is false, and therefore we have that Has(X, g"'') does not imply Computes(X, 

Note that the definition of Computes suggests that ^ because of the explicit listing of 
both sides of the disjunction. If the equality would hold, one could just define Computes(X, g"^) = 
Has(X, a) A Has(X, g*") to achieve the same result. 

Using the definition of Computes, the first axiom is given as: 

DHl Computes(X,5'''') D Has(X,g''^) 

and corresponds to the extension of the Has predicate, which can be seen by unfolding the definition 
of Computes. The second axiom states 

DH2 Has(X,c,"^) D (Computes(X, c/"'') V 3m.(Receive(X, m) A Contains(m,5°''))) 
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This axiom captures the notion that one can only possess such a term g'^^ by computing it from 
its parts, or receiving it. Effectively this restricts any agent (including the intruder) from knowing 
a term of the form g"'' at the start of each run, but it also excludes that g'^'^ is used as a parameter 
for a protocol. 

For completeness, we also give the remaining DH axioms 

DH3 (Receive(X, m) A Contains(m, g"-^)) D 

3Y, m'.(Computes(y, g"'') A Send(r, m') A Contains(m', g"'')) 
DH4 fresh{X,a) D fresh{X,g'') 

which capture the assumption that g"''' must have been either computed or received (but was not 
given as a parameter). The fourth axiom echoes the extension of the Fresh predicate. 

Summarizing, even with the extension of the Has predicate and the additional axioms, the 
behaviour of the equivalence for Diffie-Hellman is not captured in PCL, for two reasons. First, 
with respect to the execution model, the sequence of actions represented by Formula ^ cannot be 
enabled in the execution model by just changing the protocol logic. Second, we observe that given 
Has(X, h{a, b)), the protocol logic does not allow us to conclude that Has(X, h{b, a)) as one would 
expect (especially in the case where ^Computes(X, /i(a, 6))). Hence, the essential equivalence for 
any Difhe-Hellman type protocol is currently not captured in the execution model, nor in the 
protocol logic. 

4.1.2 Implications 

The Diffie-Hellman extension does not correctly capture the algebraic properties of Diffie-Hellman 
exponentials. As a result, certain possible behaviours of DH-like protocols are not considered 
within the logic and its execution model. The extension is therefore not a faithful representation 
of DH-likc protocols. 

4.1.3 Resolving the problem 

The essential feature to be captured is the equality = g'"^. If this is introduced at the term 
level, e.g. by having the equality h{a, b) = h{b, a) in the term system, this solves at the same time 
the problem in the execution model, protocol logic and proof system. Some further modifications 
to the axioms are required, and the current proofs have to be modified to take the term equality 
into account. 

4.2 Keyed hashes 

In [He05] and [HSD+05] basic PCL is extended and applied to a case study of protocols that 
do not rely solely on signatures. As observed previously, such an application requires additional 
axioms. In particular, to prove authentication, we need to introduce an axiom that allows us to 
conclude the existence of a thread. 

Appendix A of [HSD+05] gives such additional axioms and definitions for keyed hash functions: 
one definition and four hashing axioms. We reproduce them here for convenience. 

Define Computes (HASH) Computes(X, HASHK{a)) = Has(X, K) A Has(A:, a) 

As we will see in the following, the intention of this predicate seems to be to express which thread 
computed the hashed value from its components. However, this intuition is not correctly captured 
by the definition: a typical use pattern of a keyed hash would be to provide an integrity check for 
a message m, as in 

X^Y : m,HASHK{m) , (5) 

where is a key shared between X and Y. In the typical use pattern, the HASHK{m) is received 
by an agent which at that point can construct the message m himself. In this use case, the message 
hash is received with (or after) the message, and is then used to verify the integrity of the message. 
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Assume we have that m (or some subterm of it) is freshly generated by X, and we have 
that Computes{X, HA SHK{m)) holds. However, we can also prove that once a thread Y of 
the recipient Y receives the message, Y not only has K, but also m. Thus the predicate 
Computes(F, .//^^//^(m)) holds as well. Put differently, we have that for a typical use case, 
Computes(. . .) holds for both the thread who creates as well as the thread who receives. In par- 
ticular, this is also true for the protocols under consideration in [HSD+05]. The protocols in the 
paper assume typing information (no hash mistaken for a nonce) and receive the hashed values at 
a point where they know the hash components. 

Let A" be a key shared between X and Y. Then, we can prov^ the following property (invari- 
ant) for the protocols in [HSD+05]: 

Honest(X) A Has{X, HASHK{m)) D Computes(X, HASHK{m)) (6) 

Intuitively one can see that an honest agent either creates the hash by having the components, 
or receives it. In this last case, where an honest agent receives the hash, the message integrity is 
verified using the hash, which is possible only because the recipient also has both the key K and 
the message to. We will use this result in our discussion of the HASH4 axiom later on. 

The first axiom in [IISD+05, Appendix A] that uses the definition of Computes() is the following: 

HASHl Computes(A:, HASHk{x)) D Has{X, x) A Has(A:, K) 

If we unfold the definition of Computes in this axiom, it reduces to 4> Z) 4>. The second hash axiom 
states the following: 

HASH2 Computes(A:, HASHk{x)) D Has(A:, HASHk{x)) 

This axiom informally states that whoever computes the hash value also has it. If we again unfold 
the definition of Computes, we can see that this works as an extension of the closure properties of 
the Has predicate (as defined in [DDMR07]). Effectively, it introduces a new term structure fx{y) 
to the PCL syntax, and expresses the one-way property of the hash function. 
The third hash function axiom is 

HASH3 Receive(A:, HASHk{x)) D 3r.Computes(y, HASHk{x)) A Send(r, HASHk{x)) . 

This axiom is not sound. Consider the following protocol in Alice and Bob style notation, where 
TO is a freshly generated nonce of the initiator, and K' is a symmetrical key shared by the initiator 
and responder: 

Init^Resp : ENCr'^ HASHK^m)^ 

Resp I nit : HASHxim) ^'^^ 

In a normal run of this protocol, the initiator sends the hash as part of a bigger term, but does not 
send TO. Thus the responder cannot compute the hash itself, but simply decrypts the message, and 
sends the hash back. Thus, the preconditions are fulfilled by an initiator thread of this protocol, 
but the postcondition does not hold: only the initiator thread can compute it, but it does not send 
it out in the required form. (Observe that contrary to the protocols in [HSD+05], this protocol 
in ([7]) does not satisfy the typical usage pattern, and therefore Formula ([6]) docs not hold here.) 
The fourth axiom is 

HASH4 Has{X, HASHk{x)) D Computes(X, HASHk{x)) V 

3F, TO. Computes(F, HASHk{x)) A Send(y, to) A Contains(m, HASHk{x)) . 

This axiom seems to express: if someone has the hash value, she computed the hash herself, or 
somebody computed it and sent it (possibly as a subterm). 

^Note that this cannot be proven using only basic PCL, but it can be proven using PCL combined with the 
meta-reasoning required to capture the assumption that variables are typed, as pointed out in Section 13.31 
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With a suitable restriction on the intruder knowledge (the intruder should not know some 
HASHk{x) initially without knowing the components) this axiom can be proven sound. However, 
there is a problem with the applications of the axiom in the proofs of [DDMR07] . Each time this 
axiom is applied in proofs in the paper, one assumes honesty of X and Y , and that K is the key 
shared between them. Thus we can rewrite the application of axiom HASH4 using Formula ([6|), 
as in the following. First we unfold the definition of the axiom 

Honest(X) A HASH4 = 

Honest(X) A (Has(X, HASHk{x)) D Computes(X, HASHk{x)) V $) , (8) 

where $ is used to denote the right-hand disjunct of the axiom HASH4, starting from the 
existential quantifier. Now we use Formula Q to get 

Honest(X) A HASH4 = Honest(X) . (9) 

In other words, if X is assumed to be honest when applying axiom HASH4, the left-hand disjunct 
of the conclusion is always true (rendering the right-hand disjunct inconsequential). Because the 
right-hand disjunct of the conclusion contains the required thread existence, but is rendered useless, 
the axiom cannot be used here for proving authentication properties, based on our observations 
in Section [3Tn 

4.2.1 Implications 

The authentication proofs of the four-way handshake and group key handshake protocols in 
[HSD+05, He05] are not correct in their current form. The reason for this is that these proto- 
cols do not contain signatures, and based on the observations in Section l3.ll any authentication 
proofs for such protocols must rely on newly introduced axioms. In this case, the only candidates 
are the axioms HASH3 and HASH4. As shown above, HASH3 is not sound, and for the pro- 
tocols in [HSD+05,He05], HASH4 cannot be used to prove the existence of a thread. Hence the 
authentication proofs of the handshakes are incorrect, and therefore also the compositional proof 
of authentication of IEEE 802.111 is incorrect. 

4.2.2 Resolving the problem 

The properties of a keyed hash function like the ones occurring here are similar to the properties 
of symmetric-key cryptography. Thus, once sufficient reasoning infrastructure is in place for 
symmetric-key cryptography, one can devise a straightforward definition of a non-keyed hash 
function. Combining these two elements should lead to a natural definition and extension of the 
logic for keyed hashes. 

Alternatively, it might be possible to reinstate rules that were used in older works, as e.g. found 
in [DDMP04a, page 15], assuming that their soundness can be proven in the current semantics. 

5 Conclusions 

In this paper, we have first shown that basic PCL as defined in [DDMP05,Dat05,Der06,DDMR07] 
cannot be used to prove authentication properties of protocols without signatures. We consider 
this to be a strong limitation on the scope of basic PCL. Next, we have pointed out two reasoning 
tools that are missing in basic PCL: reasoning about preceding actions of a role within a thread, 
and the lack of a formal type system. With respect to PCL extensions, we have shown that the PCL 
Diffie-Hellman extension from [DDMP05,Dat05,Der06,DDMR07] does not capture the algebraic 
behaviour of Diffie-Hellman protocols correctly in the execution model and protocol logic. Finally, 
we have shown that the extension for protocols with keyed hash functions in [HSD+05, He05] is 
not sound. 
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It follows that some currently claimed PCL proofs cannot be proven within the basic logic 
as defined in [DDMP05,Dat05,Der06,DDMR07], or make use of unsound axioms. These proofs 
include the authentication proofs of the CR protocol from [DDMR07, DDMP05] and the SSL/TLS 
and IEEE 802.111 protocols from [He05,HSD+05]. 

In the papers on PCL the proofs of the invariants are often not given. This lack of proof details 
for the invariants is surprising, as the invariants themselves are the difficult part. Furthermore, 
many of the proofs seem impossible to be completed in PCL without resorting to meta-reasoning. 

Some of the problems identified here can be solved easily, but for some problems more work is 
required. For example, straightforward solutions include adding a formal type system and adding a 
mechanism to reason about earlier actions. Other problems, such as establishing thread existence 
of honest agents for protocols based on public-key cryptography, do not seem to be solvable by 
straightforward fixes, and suggest that more extensive modifications to PCL are required. 

It remains to be seen whether formal proofs in such a modified version of PCL can be concise. 
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